The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / telecomm / fnordadl / fn132man.zoo / chapter.08 < prev next >

Wrap

Text File | 1991-09-02 | 85.7 KB | 1,837 lines

Chapter 8: Networking 96 8 Networking Fnordadel has the ability to __network__, that is, to share mail, rooms and files, with other Fnordadels and other Citadels supporting the ``C86Net'' style of networking. Since Fnordadel is a descendant of Citadel-86, it retains compatibility with Citadel-86 networking (well, mostly---see Section 8.6 [Networking with Citadel-86], page 121). Other Citadel variants supporting C86Net include STadel (Fnordadel's immediate ancestor), Citadel-68K for the Amiga, Fortress, and some others. When two Citadels network, they follow a standard procedure. First, one must call the other. Fnordadel can be induced to make net calls by means of #events and #polling; read further in this chapter for more on these. Fnordadel can also receive net calls from any system at any time (assuming there's no user logged in, of course.) When two Citadels have connected for the purposes of networking, they first must stabilize the call, the caller (which starts out as the __master__) must identify itself, and passwords, if you use them, must be exchanged. Then the caller makes a series of requests; these can be for room sharing, file sending or requesting, mail delivery, or whatever. After the caller has made all of its requests, __role reversal__ is performed; this essentially makes the caller and the callee switch roles in mid-call, leaving the callee as the master and the caller as the __slave__. The callee now issues any requests that it has to make in the same manner as the caller did. When the callee is finished, the two systems hang up. Simple, huh? Well, as it happens, this simple system has proven quite flexible and useful; networking has become a fairly large part of Citadel activity. So it's only natural that it's had a large amount of programming effort devoted to it, and thus, a lot of stuff we've got to tell you about it. So hang on to your hat, and off we go! 8.1 Networking Configuration There is a whole whack of things that either need to be set or can be set in `ctdlcnfg.sys' to control Fnordadel's networking ability. We divide these into two groups: required parameters and optional ones. Please note that there is no way to ``turn off'' Fnordadel's networking ability. You may choose not to explicitly network with any systems, but other Citadels will still be able to call yours and send you mail, at the very least. 8.1.1 Required parameters These parameters *must* be defined properly in `ctdlcnfg.sys' for proper networking to occur; indeed, Fnordadel will stubbornly refuse to come up at all unless certain ones are defined. So define all these. #nodename This is a string of 19 characters or less. It defines the name by which your system will be known on the network. The allowable characters in this string are: o Upper and lower case letters Chapter 8: Networking 97 o Digits o Space characters (` ') o Any of `* _ - .' Spaces are equivalent to `_' (underscore) characters; therefore `The_Rock' and `The Rock' amount to the same thing. (We encourage the use of `_' rather than ` '; aside from our entirely subjective opinion that it looks better, it also helps when interfacing with other networks that might not support spaces in nodenames.) We'd also like to recommend against using `.' in your #nodename; it may cause confusion with domains in later versions of the software. We'd like it if #nodenames were kept to nine characters or less; indeed, configur will preach at you a bit if you define a #nodename with more than nine characters. This is mainly because of mail routing considerations (see Section 8.5 [Mail Routing], page 118); explicitly addressing mail to systems with long weird nodenames is a pain, and prone to error. We'd prefer that you used a short #nodename together with a descriptive #organization (see Section 8.1.2 [Optional parameters], page 98.) #nodeid This string, limited to 19 characters, defines the unique ID by which your node will be known. It is used by the internals of the networking software, so it will never be shown directly to users. What can this unique string consist of, you ask? Why, it's no more than your telephone number. It must follow a strict format: <country code> <area code> <phone number> Country codes are listed in Section 8.8 [Country Codes], page 123. (Canada is `CA', and the United States is `US'.) The area code and phone number are what you'd expect. Punctuation (dashes, parentheses and so on) are allowed; they're stripped when the string is actually used for anything. As an example, the following is secret's #nodeid: #nodeid "CA (403) 425-1779" #define sharedrooms This variable defines the maximum number of rooms which may be shared with any one system on your net-list. The limit has historically been 16; this value should be perfectly adequate for most systems. If you're sharing a lot of rooms (say, you're a major hub system), you'll want to put this higher. Each shared room slot occupies 10 bytes for each node in your net-list. Once you've configured your system for the first time, sharedrooms can only be changed by running nchange; see Chapter 8: Networking 98 `nchange.man' for more. Do *not* simply change the value in `ctdlcnfg.sys' and run configur; things will either come to a screeching halt (if you're lucky), or blow up violently (if you're not). #netdir This is the directory in which Fnordadel will put all the files needed in networking; these files will include `ctdlnet.sys' (your net-list), `ctdlloop.zap' (the loop-zapper database; see Section 8.4.3 [The loop-zapper], page 115), and many files of a temporary nature. Make sure this directory is on a device with some amount of free space (i.e., don't try to cram it on a floppy which has 3k free) because the temporary files written here can sometimes be fairly large if you do a lot of networking. Note that #spooldir is a synonym for #netdir. 8.1.2 Optional parameters Many of these parameters are of the ``nice to have, but not absolutely necessary'' variety. Fnordadel will try to use reasonable defaults where applicable. #organization To make up for short #nodenames (see Section 8.1.1 [Required parameters], page 96), you may define a string of up to 39 characters which will be used to provide a slightly better description of your system in networked messages. It is displayed at the end of message headers in shared rooms. For example, let's say we're running a BBS called ``The Round Table''. Now, this is longer than 9 characters, so we don't want to use it as-is for a #nodename. So, we define #nodename as `RT', which is easy to remember and type, and use an #organization like this: #organization "The Round Table, Edmonton" The headers on messages from our board will appear like this: 90Jul20 8:24 pm from Biff @ RT (The Round Table, Edmonton) The #organization field can say anything, really; some people like to put witty little sayings in there or whatever. Just keep it clean. #domain The #domain field tells the system what Citadel-86-style domain your system belongs to. A domain is a group of network systems, usually organized by geographical region, but the grouping could be based on anything at all. If you don't know what domain you're a part of, leave this field commented out or define it to be the empty string (i.e. #domain ""). You can set the field later. This field is primarily for Citadel-86 compatibility, which uses state or province abbreviations as domains. Ask around your Chapter 8: Networking 99 area to see if a domain exists, and join it if so. If not, start your own, or join a domain from another region. Please don't put a junk value in this field; leave it blank unless you're joining or starting a real domain. See Section 8.5.4 [Domains], page 121. If you define a domain, it will appear in the headers of messages originating on your system. The domains of other systems will appear in message headers from those systems. Continuing the example from above, with system RT, if we define #domain as `Alta', message headers will look like this: 90Jul20 8:24 pm from Biff @ RT.Alta (The Round Table, Edmonton) #define receiptk #receiptdir Since Fnordadel can accept files sent from other systems on the network, we have to tell it how much we're willing to accept, and where to put these files. The variable receiptk should be defined as the number of kilobytes which will be allowed to accumulate in your receipt directory before Fnordadel will refuse to accept any more files over the network. Notice that this really doesn't have anything to do with the amount of free space available on your storage device, though obviously if you run out of space, files will not be received. What actually happens is that prior to the receipt of a file, Fnordadel will add up the sizes of the files currently in your receipt directory and compare the number with your defined receiptk; if the addition of the new file would cause the total amount of used space to exceed receiptk, then the file will be refused. The upshot: clean out your receipt directory after you receive files from other systems. #receiptk defaults to `100'. #receiptdir is, as you'd expect, the name of the directory in which to put received files. If you do not define it, it defaults to #netdir. #define allnet This simple binary switch tells Fnordadel whether you want to give out net privs to all new users. If set to `1', all users will be given net privs when their account is created; when set to `0', the Sysop must explicitly grant net privileges individually (see Section 5.2 [User Status Commands], page 80). See [N]et-save in Section 3.4 [The Message Editor], page 52, and .E(nter) N(et-message) in Section 3.2.1.1 [Multi-key message entry commands], page 35, for a description of what the possession of net privs allows a user to do and how. See also `flipbits.man' for a description of a utility to set the net privilege flag for all users en masse. Chapter 8: Networking 100 #define netlog #define netdebug These two binary switches set Fnordadel defaults for network logging and debugging. If set to `1', then the logging/debugging is automatically turned on when you run Fnordadel. See Section 13.2 [Logging and Debugging], page 152. #define zaploops This binary switch tells Fnordadel to enable or disable the loop-zapper. The loop-zapper is used to control __vortexes__ in networked rooms; that is, the phenomenon whereby erroneous backbone connections somewhere along the network result in duplicate messages being sent to your system. See Section 8.4.3 [The loop-zapper], page 115. Suffice it to say that setting zaploops to `1' will enable it; to `0' will disable it. The citadel command line switch `+zap' is another way to enable the loop-zapper. #define purgenet This binary switch, if set to `1', tells Fnordadel to use its message purge feature on incoming network traffic, as well as locally-entered messages. For more information on the purge feature, see Section 10.2.10 [Message purging], page 137. In a nutshell, the feature lets Fnordadel automatically delete messages from undesireable users or entire net nodes, which you specify. Use with caution. #define keepdiscards This binary switch controls Fnordadel's treatment of incoming net messages that are discarded, either by the loop-zapper (see Section 8.4.3 [The loop-zapper], page 115) or the message purger (see above). If set to `1', the flag instructs Fnordadel to keep discarded messages in the #netdir, for you to look at later. At that time you may do such things as delete them or integrate them into the message base. See Section 8.2 [The Net Menu], page 104, for more details on the commands to handle discarded messages. If the flag is set to `0', messages discarded by the loop-zapper or message-purger are lost forever. #define forward-mail Another switch. If set to `1', it tells Fnordadel to allow mail to be forwarded through your system to others. If, for some reason, you want to disallow mail forwarding, set forward-mail to `0'. See Section 8.5 [Mail Routing], page 118. #define anonnetmail This binary switch, if set to `1', allows your system to receive net-mail from systems that are unknown to it. This is the default behavior of the system. If you have unwanted volumes of mail being dumped on you by mystery nodes, you can set this parameter to `0' and Fnordadel will reject netmail from unknown systems thereafter. Chapter 8: Networking 101 #define anonfilexfer This binary switch is like the one above, but controls file transfers with anonymous nodes. If the flag is set to `1', file transfers to and from unknown nodes are permitted. If set to `0', they are prevented. #define pathalias Here's yet another binary switch; when `1', it enables Fnordadel's path aliasing capability. See Section 8.5 [Mail Routing], page 118. #hub This is a string variable which should be set to the nodename of the system to which undeliverable mail is to be forwarded (which system, hopefully, will be better equipped to deal with it than yours is.) See Section 8.5.3 [Hubbing], page 120, for more information on #hub. #define ld-cost #define hub-cost These integer variables define the cost, measured in ld-credits, of using the Fnordadel long-distance mail routing and hub forwarding facilities, respectively. Ld-credits are given to users by the Sysop (see Section 5.2 [User Status Commands], page 80, for how to do so), and control who can send mail that costs you money. 8.1.3 Setting up for networking Networking proceeds in one of two ways: your system can call another one, or other systems can call yours. Usually you'll do both, for local network connections; for long-distance ones, you'll want to make specific arrangements. There are two mechanisms for achieving networking: events, and polling. 8.1.3.1 Network events If you don't know about events yet, go read Chapter 7 [Events], page 93. As they relate to networking, events allow you to schedule network sessions, during which your BBS will presumably call other systems (or be called by other systems) for the sole purpose of networking. The format of the event definition is laid out in Section 7.1 [Events in General], page 93; here we present an example only, with a couple of points of note: #event NETWORK all 3:01 39 ld-net 1 The above line will set up a network event which goes off at 3:01 in the morning, lasting for 39 minutes; it will be named `ld-net'; and it will apply to network #1. This means that your system will call only those nodes that are part of net #1 during this session, though calls *from* all systems will be accepted. Chapter 8: Networking 102 During a network event, the BBS is closed to the users. If a user connects, he will, after a delay, be shown a message to the effect of ``The system will be in net mode for xx minutes longer; call back later.'' If a user is logged in before an event is scheduled to go off, he will be warned five minutes beforehand that he'd better terminate quickly. When the event arrives, he will be booted unceremoniously. Upon commencing a net event, Fnordadel will call all systems in the specified net for which there is outgoing material. In addition, you can configure things so that certain nodes will be called whether there is work or not; this is known as ``polling''. (Note that this is different from #polling, detailed in Section 8.1.3.2 [Polling], page 102, below; we really must change the terminology...) See the [F] command in Section 8.3 [Editing Nodes], page 107. Note that the event will always last the specified number of minutes, whether the BBS has finished calling systems or not. Indeed, you may want to set up a net session for the sole purpose of reserving a time slot for other systems to call yours. (As we've mentioned before, Fnordadel can receive network calls at any time, whether it's in a network event or not. But setting up an event ensures that no user will be logged in.) 8.1.3.2 Polling __Polling__, in this context, refers to the ability of Fnordadel to dynamically enter network mode whenever there is outgoing work and the BBS has been idle for a set length of time. This allows greater flexibility than does the network event mechanism. Essentially, we must tell Fnordadel the time periods during which we want polling to be active; we must also tell it the required length of idle time before systems will be polled. The syntax of the #polling definition is as follows: #polling <net> <start-time> <end-time> [days] The fields mean: net The net number to poll (usually 0). start-time The time (in 24-hour format) to start polling. end-time The time to end polling. days An optional field which is either `all', or a comma-separated list of days, as in `Mon,Wed,Fri'. Most systems that engage in any local networking put a fairly standard #polling line in: Chapter 8: Networking 103 #polling 0 0:00 23:59 all This causes the BBS to poll network number 0 all day long. You can also define more than one #polling duration; for example, #polling 1 4:00 20:00 all #polling 2 20:01 3:00 all will cause net #1 to be polled from 4AM to 8PM, and net #2 to be polled from 8:01PM to 3AM. If you've got any #polling defined, you'll also want to define the variable poll-delay. This is the length of time, measured in minutes, for which the BBS must be idle before Fnordadel will start polling. A decent value (or, at least, what we use) is around 15 minutes. 8.1.3.3 Summary of network events and polling Most systems that engage in only local networking find that #polling is perfectly adequate for decent propagation times; setting up network events is usually unnecessary. Of course, if you've got users calling within 30 seconds after the previous one hangs up, you won't get much polling done; but we've never seen a system that doesn't have idle time scattered throughout the day. If you do any long-distance networking, you'll probably want to use a mixture of network events for the long-distance stuff and polling for the local stuff. It would be distinctly unwise to set up polling for nets containing long-distance systems; you don't want your board calling cross-country every time someone enters a message in the applicable shared rooms, do you? Instead, set up an event during the wee hours of the morning, and get all the long-distance networking done then. You might want to coordinate things with your long-distance connection; if both of you jump into a network event at the same time, things will go quicker. 8.1.3.4 Special keys in network events There are a couple of special keys that you can hit while Fnordadel is in a network event to make it do things. You can use these only when Fnordadel isn't in the middle of an actual net call. `^Z' __Take Fnordadel to the background__. If you run Fnordadel under some sort of multitasker, hitting `^Z' while in a network event causes the same thing as when you hit it any other time---it causes Fnordadel to drop into the background. See Section 13.6 [Multitasking and Fnordadel], page 165. `Q' __Quit Fnordadel__. Hitting `Q' while in a net event causes Fnordadel to exit completely, after confirmation. This is a good way to stop the system from calling those long-distance systems 100 times during the day. Chapter 8: Networking 104 8.1.4 Related parameters There are a few other parameters that aren't strictly networking parameters, but which will cause you networking grief if they aren't defined properly. They have to do with your modem; see Chapter 6 [Modem Stuff], page 86, for detailed descriptions. Ones to watch: #define usa #define local-time #define ld-time 8.2 The Net Menu The Net menu hides under the Sysop menu, which is reachable by hitting `^L' at a room prompt. (See Section 5.1 [Sysop Special Functions], page 75, for more on Sysop commands.) If you hit `N' at the `sysop cmd:' prompt, you'll be in the Net menu, from which you can choose one of the following commands: [A]dd node [D]iscarded messages [E]dit node [F]orce poll to node [P]oll network [R]equest file [S]end file [V]iew net list e[X]it to sysop functions [A]dd node This command allows you to add new nodes to your net-list; you must add a node to your net-list before you can send *anything* to it. You will first be asked for the node's name; type its nodename (the hopefully short name by which the other node is known.) If the system is a Citadel-86, it probably has a long and twisted name, so make sure you've got it spelled correctly, or things like mail routing, auto-reply to incoming net-mail, and other stuff won't work quite right. Names will never exceed 19 characters, in any case. Then, it'll ask you for the node ID of the new system. This is the node's phone number; it is, obviously, vitally important to get this right. It should be in the same format as your own #nodeid (see Section 8.1.1 [Required parameters], page 96). Next, you'll be queried about the baud rate supported by the new node; enter the standard baud rate code (`0' is 300, `1' is 1200, `2' is 2400, `3' is 9600 and `4' is 19200). Use the highest baud rate supported by the other node, even if it is higher than the highest baud rate that yours supports. Fnordadel is smart enough to pick the lower of the two when it dials out; and this way you don't have to edit your net-list if you happen to acquire a faster modem. Chapter 8: Networking 105 Lastly, Fnordadel will ask you whether the system is a long-distance node or not. Make sure you tell the truth here; this setting affects a number of things, including the method by which dialout is done. (See Section 6.2.4.2 [Long-distance dialing], page 91.) The rest of the settings for the new node will default to (hopefully) reasonable values. In some cases you'll have to immediately edit the node to set other things like net passwords, Citadel-86 status, and so on. [D]iscarded messages This command gets you into a small sub-section where you can view and deal with incoming net messages that were zapped or purged by your system, if you configured things to save such messages. (See Section 8.1.2 [Optional parameters], page 98, for the way to configure this; see Section 8.4.3 [The loop-zapper], page 115, for details on the loop-zapper; and see Section 8.1.2 [Optional parameters], page 98, and Section 10.2.10 [Message purging], page 137, for details on the message purge feature.) After hitting `D', the system will either tell you there are no discarded messages, or it will tell you the number of discarded messages, show you the first one, and then give you the following prompt: [A]gain, [D]elete, [I]ntegrate, [N]ext, [S]top: [A]gain Redisplay the current message and prompt again. [D]elete Delete the current discarded message, if you confirm your desire to do so, and advance to the next discarded message, if there is one. [I]ntegrate This is the interesting command. If you confirm the action, this tells Fnordadel to integrate the current discarded message into your message base as though it had never been zapped or purged. It will be passed along to any backbone systems sharing the room, just as it normally would have been. You might run into difficulty if the message was in a room that no longer exists on your system, or whose name has been changed. The same is true if the message came from an STadel or derivative, and the room is aliased there to something other than the name in use on your system, or if the room is aliased to a different name on your own system (see Section 8.4.4 [Shared room aliasing], page 117). In any of these cases, Fnordadel won't know where to put the message now, so it will ask you if placing the message in the Aide> room is okay. Once it's there, you can move it. If you don't okay the placement in Aide>, nothing is done. Chapter 8: Networking 106 If the message is successfully integrated into a room, you will be asked if the discard message file should be deleted, and then shown the next discarded message, if there is one. If the message is not integrated, you will be returned to the discard prompt. [N]ext Take you to the next discarded message, if there is one. [S]top Stop the discard message processing and return you to the net commands menu. [E]dit node This command takes you to the net node edit sub-menu. See Section 8.3 [Editing Nodes], page 107, for an in-depth look. [F]orce-poll node This is a quickie command for forcing Fnordadel to make a single net call to another system. Supply a system name, and Fnordadel will call the system regardless of traffic pending, receive-only status, l-d status or anything else. [P]oll network This command allows you to force a one-time poll of the specified network. If anyone is logged in at the time, they will be immediately terminated (with extreme prejudice, we might add) and Fnordadel will call all nodes in the specified net for which there is work. [R]equest file Use this command when you wish to get some files from some system with which you network directly. You'll be asked for the system from which to request files, the room on the other system from which to get them, the filename(s) to get, and the directory on your system in which to place the received files. The room on the other system must be ``network readable'' (see Section 8.4.1 [How to share a room], page 112) for the request to work. You may use wildcards (`*' and `?') in the filename specification. The file request will be spooled for later; the next time your system connects with the other one, the request will be made and, if the other system can oblige, the files will be transferred. Note that it is possible to request files from a system with which you have not previously networked. Simply add the node to your net-list in the standard manner, and `[R]equest' the file as usual---the other node doesn't have to know about yours. (We use this in the distribution of Fnordadel; any other node can call us and request new versions, assuming they know the name of the room and the filenames. See Appendix A [Fnordadel Support], page 170.) Chapter 8: Networking 107 [S]end file This command allows you to send a file or files to a node with which you network directly. You'll be asked for the target node name and the name(s) of the file(s) to transfer; you should provide the full path-spec, and wildcards (`*' and `?') are permitted. The sendfile will be spooled for later; the next time your system connects with the other one, the sendfile will be made, subject to space availability on the other system. If there wasn't enough space, the other node will say so and you'll get a message in Aide> to this effect. You will have to re-enter the send command once the remote system has corrected its space problems. [V]iew net list This prints out a nicely formatted list of all the nodes in your net-list. The format is as follows: * sysname CA 403 432 1098 CRMF 2400 0,1 ^ ^ ^ ^ ^ ^ | \ | | | | "need the name of the nodeId various baud | to call" the node (phone number) flags rate | flag | | nets to which the node belongs The ``various flags'' may consist of one or more of the following: `C' The system is a Citadel-86 `R' The system is receive-only (i.e., your system will never call it) `M' There is mail pending `F' There are file sends/requests pending The ``need to call'' flag (the leading asterisk) appears if there is any work pending for the node; it doesn't mean that your system will call the node, because the node may be set to receive-only. (See Section 8.3 [Editing Nodes], page 107.) e[X]it to sysop functions This should be blatantly obvious. 8.3 Editing Nodes There is a sub-menu under the Net menu (which is itself a sub-menu under the Sysop menu; see Section 8.2 [The Net Menu], page 104) which allows you to edit various things pertaining to nodes in your net-list. Nodes must obviously be added to the list before they can be edited, using the [A]dd node command; again, see Section 8.2 [The Net Menu], page 104. The commands on the node edit menu are as follows: Chapter 8: Networking 108 [A]ccess setting [B]aud setting [C]- set receive-only status L[D] role reversal [E]xternal dialer setup [F]- set polling days [I]D change [K]ill node from list [L]ocal setting [N]ame change [P]assword settings [R]ooms shared [T]oggle Cit-86 status [U]se nets [V]iew node configuration e[X]it net editing [Z]- set l-d poll count [A]ccess setting An access string is an alternate way of dialing a system. Normally, the dial command for the modem is formed by taking the last seven digits of the node ID (for local systems), or the full ten digits, i.e., including the area code, prefixed by a `1' (for long-distance systems), and sandwiching this between the dial prefix and the dial suffix. (This all assumes that you've got #usa defined in `ctdlcnfg.sys'; see Section 6.2.4 [Dialing out], page 90, for more on this stuff.) But if you specify an access string, Fnordadel forgets all of the above, and simply spits the access string at the modem (still sandwiched between the dial prefix and suffix.) You'd use this if you're dialing a country other than Canada or the USA, for instance, or if you're dialing a system which is long-distance but within your area-code. (Some telephone systems don't like it if you dial 1-areacode-number within the areacode.) Because the string is used as-is, you can embed any special dialing commands that your modem supports, like `,' to pause the dial or whatever. The access string is also used as a command line to pass to an external dialer that you may have set up for this node; see below. [B]aud setting This allows you to change the node's baud rate. The acceptable values here are the same as elsewhere in Fnordadel: `0' is 300 baud; `1' is 1200 baud; `2' is 2400 baud; `3' is 9600 baud; and `4' is 19200 baud. Note that Fnordadel will never attempt to call out at a baud rate higher than the highest rate supported on your system; so it's perfectly safe to list a system at 19200 baud if you're only running on a 2400 baud modem; one day, you too may have a 19200 baud modem, and when you do, your BBS will be ready for it! Chapter 8: Networking 109 [C]- set receive-only status A node can be set to __receive-only__, which means that Fnordadel will never dial out to it, even if there is work pending for that system---you'll have to wait until the other system calls yours. If you're entering nodes into your net-list for the sole purpose of dialing out to them manually using the [T]elephone command, (i.e., they aren't Citadels), then set receive-only status to prevent an accidental network callout. L[D] role reversal This is somewhat of an outdated command; it allows you to specify whether role-reversal will be performed with this (presumably long-distance) system. It defaults to Yes, so you should never have to muck with it. [E]xternal dialer setup Fnordadel allows you to define an external dialer for each net node; that is, a program which will do the work of dialing and connecting with the system. The main use for this is if you're using some sort of service like PC-Pursuit, or a packet-switched network, or whatever. When using this command, specify the external dialer number; Fnordadel expects to find the external dialer programs in your #netdir, named `dial_n.prg', where n is the dialer number. If you have an external dialer set for a node, it will use the access string as the command tail to pass to the dialer. So, say you're using PC-Pursuit. You've taken the PC-Pursuit dialer program and put it in #netdir as `dial_1.prg'. You've set the external dialer (using the [E] command) to "1". You've set the [A]ccess string to `-x foobar'. When Fnordadel dials this node, it will run the program so: `#netdir\dial_1.prg -x foobar'. When the dialer program finishes, there should be a carrier present and the baud rate should be set up correctly, assuming the call connected. Fnordadel will then proceed with networking as normal. [F]- set polling days Despite the fact that this command has the word ``polling'' in it, it in fact has nothing to do with #polling (the ability to make net calls at any time.) Rather, this command lets you specify the days on which the net node will be called *whether there is work pending or not*. The calls will still happen only during applicable network events. This allows you to, say, regularly call a long-distance network feed to pick up stuff, even when there is no outgoing work pending. The format of the days specification is any of `Mon', `Tue', `Wed', `Thu', `Fri', `Sat' and `Sun', separated by commas. So `Mon,Wed,Sat' is a valid specification. (This format is the same as that used in the #event and #polling definitions; see Section 8.1 [Networking Configuration], page 96.) Chapter 8: Networking 110 [I]D change When a system with which you network changes its phone number, you'll have to make the change in your net-list, and this is how. Just enter the standard node ID format: <country> <area code> <number> as in `CA 403 425 1779'. Note that if you change the node ID of a system, the loop-zapper records for that node will be invalidated. The loop-zapper will pick up the change as a matter of course (it will look like a new system, as far as the loop zapper is concerned), so this isn't a problem or anything. [K]ill node from list This command will remove a node from your net-list. Simply type its name; Fnordadel will ask you for confirmation before it kills the node. Currently Fnordadel does not unshare all the rooms that this system was sharing; you must do so manually before using this command, or things may screw up later on. (Edit the room and type `U'; see Section 4.2.1 [Sysop room-editing commands], page 70, and Section 8.4.1 [How to share a room], page 112.) The confirmation prompt will remind you of this fact, in case you forgot. [L]ocal setting This command is for telling Fnordadel whether this system is long-distance (i.e., out of your local calling area) or local. You do want to be accurate with this; don't fib. [N]ame change If the node has changed its nodename, you'll want to make the corresponding change in your net-list to keep everything working smoothly. Just type in the new name. [P]assword settings If you suspect security problems when networking with this node, then set the passwords. They must be agreed upon by you and the other Sysop beforehand. You'll define the password that your system uses when calling the other one, and the password that your system should expect from the other when it calls you. They may be the same, though for optimum security you'd want them different. Please note that Citadel-86 systems use a different form of net passwords, and therefore you must tell Fnordadel that this node is a Cit-86, or passwords will not work. See [T]oggle Cit-86 status, below. [R]ooms shared This command prints out a list of the rooms that your system is sharing with this node. Rooms with messages that need to be sent to the node are flagged with an asterisk. Chapter 8: Networking 111 [T]oggle Cit-86 status Actually, it's not a toggle, but [C] was taken. Anyway, if the node is a Citadel-86 system, you should tell Fnordadel so by using this command. The value of this flag is checked for things like file requests, network protocol changes, and net passwords, so it is essential to turn the flag on for Citadel-86es. Note that direct Cit-86 derivatives like Citadel-68k for the Amiga are functionally identical to Cit-86 (as far as networking goes) so you must turn this flag on for them as well. [U]se nets Fnordadel uses the concept of __net numbers__ to form logical groups of systems. When you first enter a net node into your net-list, it defaults to being a member of net number 0. But you can set it up so that it's a part of a different net, or several nets at once---valid net numbers are from 0 to 31. These net numbers are referred to in network event definitions (a node must be part of the net to which the net event applies for Fnordadel to call the node during the event) and in polling (which applies to specific net numbers). You may also remove a node from all nets; this has the effect of removing it from the standard list of valid net nodes printed out when a user hits `?' when asked for the target system of a piece of net-mail; and also removes it from consideration when the system is trying to route net-mail (see Section 8.5.2 [Path aliasing], page 119). The format of the [U]se nets specification is as follows: To add a node to some nets while preserving the current settings, use `+netlist'. To remove a node from some nets, use `-netlist'. To specify a totally new set of nets, just use netlist. What's a netlist, you ask? It's just a series of net numbers delimited by commas or spaces. For example, if the node is currently in net 0 and 2, and you wish to add it to net 5, type `+5' when asked for the nets you want to use. To remove a node from net 0 (the default net), type `-0'. [V]iew node configuration This command prints a quick summary of the settings for this node. e[X]it net editing This exits back to the Net menu. [Z]- set l-d poll count You can tell Fnordadel how many times you'd like it to attempt to call an l-d system during an event before giving up, hence this command. Normally the system will be called until Fnordadel obtains a carrier, and then will not be called again during that session, whether the call was a complete success or not. This command overrides that; just specify the number of calls. Chapter 8: Networking 112 8.4 Roomsharing For most systems, the primary purpose of networking is to share rooms. Rooms designated as shared (or ``networked'') by the Sysop will have all messages entered in them sent to the systems with which he has shared the room; the other systems have, presumably, set up the same thing, and so you end up with a sort of super-room spanning several BBSes. (There are zillions of little exceptions and modifications to the above description, which we'll let you discover for yourself.) 8.4.1 How to share a room To make a room shared, you need to edit the room. This is accomplished by .A(ide) E(dit) while in the room in question; you must have Aide status (and be logged in, naturally) to use this. In this menu you'll find a few useful commands, detailed here. (For more on the room edit menu, see Section 4.1.2 [The .A(ide) command], page 63, and Section 4.2.1 [Sysop room-editing commands], page 70. These are the commands we're interested in here: [S]hared [U]nshare [Y]- toggle backbone status [N]et readable [Z]- autonetted room [P]ermanent [S]hared Use this command to make a room shared to start with, and also to add new systems to the shared list for this room. When you hit `S' you'll be asked if you want to make the room shared; answering ``no'' will make the room not shared and return to the menu. (If the room was shared before, it will still be made unshared, but no nodes will be removed from the shared list for the room. This may cause strange behavior, so be careful.) If you answer ``yes'', Fnordadel will ask for a list of net nodes with which to share the room. Typing a `?' will list the choices available to you; systems must be in your net-list, obviously, before you can share a room with them. Simply enter the name(s) of the nodes, one at a time, with which to share the room, and enter a `<CR>' with no node name at the prompt to finish. [U]nshare Use this command to remove one or more systems from the sharing list for this room. Simply type their name(s), one at a time, and finish with a `<CR>' at the prompt. If you want to make the room completely unshared, i.e., not a network room any more, use this command to disable each node currently connected to the room. Then use [S]hare, and answer ``no'' to make the room non-networked. [Y]- toggle backbone status This command lets you turn backboning on or off for one or more nodes with which the room is being shared. See Section 8.4.2 [Topography and backboning], page 113, for more on backboning. Chapter 8: Networking 113 [N]et readable This command tells Fnordadel whether files can be requested from this room over the network. It has no effect if the room is not a directory room, obviously. If you set the room to be not network readable, then any and all file requests for this room will be refused. [Z]- autonetted room In a normal shared room, messages are only saved as Networked messages if the authors have net privileges; this can, however, be overridden using the __autonet__ feature. If a room is autonet, all messages entered in it are saved as net messages, regardless. Use this with caution. Especially if the room is a long-distance networked room, you could be in for a rude shock if a ruggie phones and dumps a load of rubbish into it---you'll pay to send it all out over the net, and all the other systems sharing the room will likely be very peeved. [P]ermanent This is not strictly a networking option, per se, but it rates a mention. If a room is shared, you'll likely want to make it permanent to stop Fnordadel from automatically expiring it if it empties of messages. (Say, if you haven't managed to call the feed for a while, or whatever.) Other systems tend to get peeved if shared rooms start dropping off your system without any advance warning, since their Aide> rooms will fill up with warnings when they attempt to resume sending messages. 8.4.2 Topography and backboning The standard room sharing method, used for most local connections, is for every system carrying a given room to share the room with all other systems carrying it. This kind of arrangement would look like this: ---NodeA--- Every system is sharing the room / | \ with every other system. NodeB------)-----NodeD \ | / ---NodeC--- The main advantage in this setup is that it's quite robust. If a system suddenly drops off the net, it won't disrupt anything (topography-wise, that is; people will probably notice, but it won't necessitate any change in the room sharing method.) However, it's not very efficient in terms of aggregate time spent doing networking. Whenever there are new messages in the shared room, each system has to call all the others. In addition, this method is totally insane if the systems are not local to each other, or if there is a large number of systems sharing the room. So, backboning was invented. Chapter 8: Networking 114 Backboning allows network messages to be passed on to another node even if they weren't entered on your system. More specifically, if you turn backboning on for a given system, say foobar, in a given room, all messages received by your system (except from foobar itself, of course) in that room will be sent out to foobar, in addition to all messages entered locally on your system. What this does to the net map is allow much greater flexibility in connections. First, here is an example which employs a central hub system with lots of little ``spokes'': NodeI NodeB NodeC NodeA shares the room with \ | / all systems, while all the \ | / other systems share the NodeH----NodeA(Hub)----NodeD room only with NodeA. NodeA / | \ turns backboning on for all / | \ systems; the other systems NodeG NodeF NodeE do not use backboning. This arrangement will basically shift the bulk of the net load to NodeA. The other nodes will not know that any backboning is going on; they will simply share the room in the standard manner with NodeA. NodeA is responsible for passing all of the other systems' messages on to all the other systems by turning on backboning. This works pretty well in local situations, and in long-distance situations where the cost of calling NodeA is not much different than calling any one of the other nodes. No node is ever more than two hops away from any other, and so propagation times are good. In local situations you might want to use this arrangement to reduce the aggregate time spent in net mode by concentrating it on NodeA; the other systems will only have to make one net call every time new messages are entered, instead of many calls. However, you've probably noticed a drawback---if NodeA ever disappears, the sharing scheme has to be redone, possibly by promoting one of the other systems to be the hub. In long-distance situations, there are often more cost-effective ways of arranging things. Here's another example: NodeC NodeH Nodes B, C, F, G and H \ / share as normal; \ / Nodes A, D, and E flag NodeA---NodeD---NodeE---NodeG all other systems as / | backboned. / | NodeB NodeF This arrangement allows NodeG, for example, to net with NodeE instead of a (possibly more distant) hub like NodeD. It allows Nodes A, B and C to rely on NodeD for their feed (we assume in this example that A, B, C and D are all local to each other.) (In this case, it would be nice if the Sysops of A, B and C helped with NodeD's phone bill.) Chapter 8: Networking 115 There are many variations on the above examples; the guiding rule is that if you wish to pass messages on to another system, turn backboning on for that system. But be *very very* careful that loops are not introduced in the net topography, or you'll have a ``vortex''. NodeC NodeH Nodes B, C, F, G and H /\ / share as normal; / \ / Nodes A, D, and E flag NodeA--NodeD---NodeE---NodeG all other systems as / | backboned. / | NodeB NodeF This modification of the previous example illustrates how a vortex can happen. NodeA and NodeD are each backboning a room to all their net connections. NodeC incorrectly decides to share the room with both NodeA and NodeD. Thus, every message entered on NodeC is sent to both NodeA and NodeD. But because NodeA and NodeD backbone the room to each other, they also send all of NodeC's messages to each other. NodeD will also send the duplicates out to NodeE, which will propagate them to its local connections. This obviously causes a lot of duplication (and expense, if there are any long-distance connections). To automatically detect and eliminate this vortex problem, a loop zapper was developed. 8.4.3 The loop-zapper With the advent of backboning came sloppy net management. (Well, we suspect that the sloppy net management was around before, but it never had such a good opportunity to manifest itself.) Anyway, if your room sharing arrangement has a loop in it, you have what we in Edmonton dubbed a __vortex__. (The term appears to have gained national popularity.) The loop-zapper is a brute-force method of stopping vortexes. The way it works is pretty simple. Each incoming networked message has in it the node ID of the originating system, the date and time on which the message was created, and possibly a message ID number from the system that originated the message. Fnordadel keeps a database in which it stores the node IDs of all systems from which it has ever---directly or indirectly through backboning---received a message. For each node ID, Fnordadel then records the date of the latest message to be received, and what its message ID number was (if any; STadel does not pass along such information, but Cit-86 and its clones for other machines do, as does Fnordadel). Moreover, this is done in each room in which messages have been received. So when new messages come in, the node IDs, dates, message ID numbers and rooms of the messages are checked against the loop-zapper database. If a message o is dated earlier than the latest one received in that room from that node, and Chapter 8: Networking 116 o has a lower message ID number than is recorded in the database it is assumed to be an old message coming back again, and will be rejected. A message to that effect will be printed on the screen (and in the net-log, if you're keeping one.) To enable the loop-zapper, either define the `ctdlcnfg.sys' variable zaploops to `1', or invoke citadel with the command line argument `+zap'. The loop-zapper database is kept in your #netdir as `ctdlloop.zap'. If you happen to delete this file, you'll have to reconfigure and start the loop-zapper again. The loop-zapper will be built as the messages come in; you can also build a loop-zapper which reflects your current message base by running the utility makezt. The contents of your loop-zapper database may be viewed by using the utility scanzt. See the respective man pages for directions on using these programs. Fnordadel tries to be smart about detecting truly looped messages, versus ones that are abnormal but not duplicates. This is why it checks both the date/time stamp *and* message ID number of each message, and only rejects those where both values are older than the database shows. For example, it's possible for a glitch or system crash on another system to cause it to start sending you messages with message ID numbers that look old; but if the dates are new, the messages will be accepted, not rejected, on the assumption that the other system's message ID counter got reset to a value lower than before. Likewise, the clock may have been screwed up on some other system (e.g., its clock got set to some point in the future, some messages were sent out, and its clock is now back at the correct value, or else it got set to some point in the past and hasn't been corrected yet). Your loop-zapper database will thus show a date/time that is greater than the one on the incoming messages, but as long as the messages have new message ID numbers, they will be accepted, not rejected. Note that no version of STadel ever sends the message ID number, so the loop-zapper only has the date/time stamp to work with. Thus it's easier for Fnordadel to mistakenly start zapping messages from an STadel, if that node's clock got messed up. The Fnordadel loop-zapper database is also self-correcting to some degree. When any message is accepted in a room, both its date/time stamp and message ID number are recorded as being the newest ones seen, even if they are lower than what was there before. In this way, your database will weed out incorrect date/time values, or message ID numbers. It can't weed out both if they occur simultaneously, though; if a new message comes in and has the bad luck of having an old date/time and an old message ID number, the loop-zapper will reject it. If you ever have a node get screwed up and the database doesn't seem to correct itself, the only way to stop Fnordadel from zapping all the node's messages is to delete your `ctdlloop.zap' file and start from scratch. Run the makezt utility to build a new database from your current message base, or just let Fnordadel run and accumulate new information over time. From time to time, your system may incorrectly zap a small number of messages from one or more nodes, and then return to normal. Zapped messages can be saved off-line if you so desire (see keepdiscards in Section 8.1.2 [Optional parameters], page 98.) You may then read through Chapter 8: Networking 117 them and optionally delete them permanently or tell Fnordadel to integrate them into your message base (if they look like they were zapped in error). See Section 8.2 [The Net Menu], page 104, for instructions on these commands. Although the loop zapper is quite smart, there's currently one glitch in it. You may notice that if two identical messages come in during the same network call, the zapper will let both of them all through. Hey, so it's only close to perfect... 8.4.4 Shared room aliasing If you don't like the standard name by which a shared room is known on the network and would like to have that room differently named on your system, you can accomplish this using shared room aliasing. Simply put a file called `alias.sys' in your #netdir. It should consist of `<TAB>'-separated fields as follows: <system> <roomname> <alias> <system> is the name of the system to which the alias will apply; the special name `%all' makes the alias apply to any and all systems with which you share the room. <roomname> is the name of the room on your system. <alias> is the name of the room on the other system(s). We actually recommend against using the aliasing feature unless there's a really good reason for doing so. The standard room names are usually fine, and more importantly, it's possible to alias a room to another name and then share the room with another system; the Sysop of the other system may not realise that the room he's getting from you is the same as the standard net room and may decide to share it with yet another system in such a way as to create a vortex. So if you use this feature, be very careful. Also note that if you are sharing aliased rooms with a system, and change the name of that system in your net list, you must exit Fnordadel and edit `alias.sys' to update it with the system's new name. If you don't, Bad Things will happen. 8.4.5 A few hopefully wise words o Be considerate when sharing or unsharing rooms with a system. If you tell another Sysop to share a room with you, make sure you've shared it with him, or his Aide> room will be flooded with messages reporting that your system isn't sharing the room with his. Chapter 8: Networking 118 o We've already mentioned this, but it bears repeating any number of times: Be careful when using backboning, and when sharing rooms in general. Make sure you understand the topography of the room in question before messing about; you don't want to cause a vortex, do you? <PROD> No, you don't. o Please try to police the net rooms. This applies especially to the national networked rooms, which cost people money to transport. If you have a twit or two who are entering stupid messages (or, worse, ``vandalism'' type of stuff like 10K of profanities and so on), it is up to you to stomp on it as soon as possible. Moreover, you must also be on the lookout for what Citadelians refer to as __room drift__; if users on your system start talking about Pascal programming in a networked Religion room, you must put a stop to it. Please be considerate for your fellow Sysops downstream. o You should be aware that there are some incompatibilities between systems descended from STadel and those directly descended from Citadel-86. We are working on eliminating them all in Fnordadel, and hope eventually to make Fnordadel a seamless connection between the STadel network and the Cit-86 network. For the time being, not everything works perfectly. See Section 8.6 [Networking with Citadel-86], page 121. As for normal room sharing, you should have only one real problem any more: Cit-86 messages can only be 7500 characters long, while STadel and Fnordadel messages can be 10000 characters long. Thus long-winded people posting on your system will get cut short if the messages migrate over to a Cit-86. This could cause some confusion. 8.5 Mail Routing Another popular use for the Citadel network is for private mail. In the simplest case, that of sending mail to another user on the same system, mail delivery is an understandably easy job. When you want to send mail to a user on a system which connects directly with yours, it's also a pretty easy thing. However, when you want to route mail through one or more intermediate nodes before it reaches its destination, things get a little tricky. This section details a few helpful features designed to make mail routing simpler and more effective. 8.5.1 Net addresses When you go to the Mail> room and hit [E]nter, the system asks you to tell it to whom you want to send the mail. If the mail is going to be a networked message, you have two ways in which the address can be specified. One is using `@' notation, and the other is using explicit __bangpaths__, which have as their distinguishing feature the `!' character as a separator. The two forms produce identical results; it's just a matter of taste, really. The `@' form is as follows: Chapter 8: Networking 119 user@system which means that you wish to send the mail to the user named user on the node called system. The bangpath form is like this: system!user which means the same thing as the previous example. If you want to send mail through several nodes, you'll have to provide a `To:' address something like this: node_a!node_b!node_c!user , or perhaps node_b!node_c!user@node_a As you'll notice, the `@' and `!' forms can be mixed. The two examples above both address the mail to a user on `node_c', which (we happen to know) is reachable by a direct path from our system to `node_a' to `node_b' to `node_c'. Your system may also receive routed mail from other systems with which it networks. If the mail is destined for a user on your system, then it is delivered to that user and the message stops. But the message may be addressed to someone on a system further on. If you want your system to be able to pass such mail on, you'll have to make sure that the `ctdlcnfg.sys' variable #forward-mail is defined as `1'. If it's `0', your node will simply reject all routed mail. 8.5.2 Path aliasing So, forming net addresses is easy, right? But it's a pain to have to remember explicit addresses through half a dozen other systems to reach the one you want. So Fnordadel allows you to define, once and for all (or until you change the definition), the paths to systems. Then when someone wants to send mail to someone on such a system, they need only type a `To:' field of `user@system', and let Fnordadel figure out where `system' is. You can also use the path aliasing feature in strictly local situations; if you have, say, a Citadel-86 system with a really weird nodename, you can alias it to something short and essentially pretend that its name (for the purposes of net mail) has changed. The way it works: First of all, if you want to enable the path aliasing feature, you should define the `ctdlcnfg.sys' variable #pathalias to be `1'. If it's `0', Fnordadel won't even bother. The path alias data is stored in a file called `ctdlpath.sys' in your #netdir. When someone enters a message addressed to an unknown node, Fnordadel looks in this file for an alias to the unknown system. (Note that ``unknown'', in this context, means any system which is not in your net-list, or which is in your net-list and is not a member of any nets. See the [U]se nets command Chapter 8: Networking 120 in Section 8.3 [Editing Nodes], page 107. Also note that incoming mail from other nodes is subjected to the same treatment; Fnordadel doesn't care whether the mail is local.) If it finds an address, it will substitute this into the `To:' field of the message and mail the message off to its target. If the message was local, there may be special charges (in terms of ld-credits) which apply to the message; see Section 8.1.2 [Optional parameters], page 98, on the `ctdlcnfg.sys' variable #ld-cost for one such cost. The `ctdlpath.sys' file consists of `<TAB>'-separated lines of the form: alias path [surcharge] where alias is the nodename being aliased; path is a string defining the path to the node; and surcharge is an optional number of ld-credits which will be charged to the user for using the aliasing feature. Here is a sample `ctdlpath.sys': devnull `<TAB>' poopsie!%s `<TAB>' 1 alberta `<TAB>' dragos!myrias!%s `<TAB>' 2 Backfence `<TAB>' Backfence [MN] `<TAB>' 0 Silly `<TAB>' Silly_Cit-86_Name[MN] `<TAB>' 10 The special sequence `%s' means ``the destination node''. In this example, let's say we wanted to mail to `Holly' at the system `devnull'. We enter a `To:' field of `Holly@devnull'. Fnordadel discovers that `devnull' is not in our net-list, so it reverts to Plan B---path aliasing. Searching `ctdlpath.sys' for an entry for `devnull', it finds that the route to `devnull' is through `poopsie'; so it massages the path into `poopsie!devnull' (since the alias specified `poopsie!%s', and `devnull', the destination system, is substituted for the `%s'). After appending the user name to the whole thing, the `To:' field is `poopsie!devnull!Holly'; Fnordadel now spools the mail for delivery to `poopsie'. The user who entered the mail is charged two ld-credits---one for the fact that it's long-distance mail, and one for the surcharge listed in `ctdlpath.sys'. Or, in the above example, if we wanted to send mail to a user on `Silly_Cit-86_Name[MN]' and didn't want to make our users or ourselves type that, we'd simply be able to give a `To:' field of `user@silly' and let Fnordadel worry about it; it would check the alias file and use the entry therein to massage the `To:' field to `Silly_Cit-86_Name[MN]!user'. 8.5.3 Hubbing What happens if your system gets mail addressed to an unknown node, and it doesn't have an alias defined for that node? If you have defined the `ctdlcnfg.sys' variable #hub, then your system will have a last resort. All mail which cannot be dealt with either by direct connection with the target system, or by an explicit path in the message in which the first node in the path is directly connected, or by path aliasing, will be forwarded to the system defined as your #hub. This system (hopefully) will be better able to deal with the mail than yours was, either because it is connected to more systems directly, or because it has a more extensive path alias file than you have. Chapter 8: Networking 121 Mail which is entered locally and is forwarded to the #hub for delivery can be charged extra ld-credits based on the setting of the `ctdlcnfg.sys' variable #hub-cost---see Section 8.1.2 [Optional parameters], page 98. 8.5.4 Domains Domains are supported in this version of Fnordadel, but in a somewhat superficial manner. Primarily for Citadel-86 compatibility, you can set the value of a `ctdlcnfg.sys' parameter called #domain, to tell Fnordadel what Citadel-86-style domain you are in. See Section 8.1.2 [Optional parameters], page 98. Citadel-86 uses this field for domain mail, a feature Fnordadel does not yet support. We also have some additional domain support. By placing lines beginning with a period (`.') character into `ctdlpath.sys', we can tell Fnordadel information about what other domains we are a part of and about how to reach other domains. For example, consider the following lines in `ctdlpath.sys': .uucp `<TAB>' foobar!%s `<TAB>' 1 .citadel .uucp These lines define us to be members of the `.citadel' and `.uucp' domains; in addition, they specify that any mail bound for the `.uucp' domain is to be routed through `foobar' (and to be charged, in the local case, an additional ld-credit.) Look for better domain support in later versions. 8.6 Networking with Citadel-86 Originally developed by Hue, Jr., back in the early days of Citadel-86, the Citadel networker is a fairly flexible beast. Indeed, it has proved so flexible that numerous Citadel developers have mutated it in a variety of interesting ways. A major mutator, so to speak, was David Parsons (orc), who did STadel, from which Fnordadel is descended. Some of the improvements and changes resulted in incompatibilities with Cit-86 networking. It is our intention to eliminate or work around all of these things at some point, hopefully in the near future. In order to make your Fnordadel work as smoothly as possible with a Cit-86, you should set the Cit-86 status flag for it in your net list, and ask its Sysop to set the STadel status flag for your system in his net list. As of this writing, the following are the areas in which Cit-86 and Fnordadel networking differ: o Mail routing has been done in remarkably different ways. Cit-86 supports STadel-style mail routing as a sort of after-hack, but don't rely on it too much. (Similarly, don't tell your local Cit-86 friends to rely on you too much for mail routing, either.) Chapter 8: Networking 122 o Fnordadel currently has minimal support for Cit-86 domains, although it will set the domain field on locally-originating messages, and pass through the domain field on net messages from other systems. See Section 8.1.2 [Optional parameters], page 98, and Section 8.5.4 [Domains], page 121. o Cit-86 supports a networking option to compress network information on the fly. Fnordadel does not yet support this facility. This will probably cause you to see messages something like ``Reply BAD: <10> unknown'' during networking sessions. This is nothing to worry about. o Cit-86 doesn't use the #organization field, or pass it on to other systems that it nets with, so in backboned shared rooms, messages from your system will lose the #organization field the first time they pass through a Cit-86. o Cit-86 also doesn't support the STadel message subject field. o Cit-86 messages are limited to 7500 characters in size, while STadel (and its descendants) support messages up to 10000 characters long. Thus when your messages pass through a Cit-86, they may get chopped short. The following are incompatibilities which we inherited from STadel, but which we have fixed: o The network sendfile/file request methods used to be different; sending files to a Cit-86 would work (and sendfiles from the Cit-86 to you would also work), but file requesting (in either direction) wouldn't. This is now fixed---everything should work. o Fnordadel and Citadel-86 couldn't use the Ymodem protocol during netting; they should be able to now. o The network passwords should work fine now. The following things are bits of funny business between Cit-86 and Fnordadel, but are harmless: o If a Cit-86 is backboning any rooms to your system, you may notice that each time it nets with your system, it will attempt to send each backboned room, whether or not there are any new messages to be transferred. (It will send 0 messages, basically.) We can't imagine why it does this, but it seems to be normal and will not cause a problem. o There are net commands that Cit-86 supports but Fnordadel doesn't, and possibly vice versa. In particular, Cit-86 has two commands that Fnordadel doesn't yet know about: 8 (a different form of room-sharing) and 10 (for data compression during networking). They will cause messages during networking, such as ``Reply BAD: <10> unknown'', when a Cit-86 asks your system to carry out such a command. These are nothing to worry about. Chapter 8: Networking 123 8.7 Interfacing to Other Networks Using the #event mechanism, custom networking software and (often) lots of system resources, it is theoretically possible to make your Fnordadel talk to just about any other network in existence. Of course, most of the custom software has never been written, so it's largely theoretical. STadel had a program called uucall, which was for talking to Unix machines using the UUCP protocol, and allowed incoming and outgoing mail and News (the Usenet analogue to rooms). uucall is not currently supported by Fnordadel (and thus, is not included with it); it needs some hacking. If anyone is strongly interested in seeing it running, let us know---we occasionally need a bit of encouragement. Our plans are, tentatively, to redo the UUCP support using a different approach, but the uucall code is there, and with a little effort could be made to work---it worked with Fnordadel for a long time, and then broke when we changed something or other, and we've just never gone back and fixed it. STadel also had a program called bixcall, which was for talking to the Byte Information eXchange (BIX). We've never seen BIX in our lives, so we've no way of testing it at all. We can send a copy to anyone running Fnordadel and you can see if it works; there isn't much we can do to support it, though. 8.8 Country Codes Country codes are used in your #nodeid (see Section 8.1.1 [Required parameters], page 96; they consist of one to three letters which uniquely identify your country. The following list is considered standard; it is purloined directly from `COUNTRY3.MAN', in the Citadel-86 documentation. Abu Dhabi AH Afghanistan AF Ajman (U.A.E.) JM Albania AB Algeria DZ Andorra AND Angola AN Anguila LA Antigua AK Argentina AR Australia AA Austria A Bahamas BS Bahrain BN Bangladesh BJ Barbados WB Belgium B Belize BH Bolivia BV Botswana BD Brazil BR Brunei BU Bulgaria BG Burma (Union of) BM Burmuda BA Burundi UU Cameroon Republic KN Canada CA Cayman Islands CP Central African Empire EC Central African Rep. RC Chad Republic KD Chile CF China (People's Rep) CN Colombia CO Congo Republic KG Cook Islands (Rarotonga)RG Costa Rica CR Cuba CU Cyprus CY Czechoslovakia C Denmark DK Djibouti, Rep of FS Dominica DO Dominican Republic DR Dubai (U.A.E.) DB Chapter 8: Networking 124 Ecuador ED Egypt, Arab Rep. of N El Salvador SAL Ethiopia ET Falkland Islands FK Faroe Islands FA Fiji Islands FJ Finland SF France F French Guiana FG French Polynesia FP Fujairah (U.A.E.) FU Gabon Republic GO Gambia GV Germany (Dem. Rep) DD Germany (Federal Rep) D Ghana GH Gibralter GK Greece GR Greenland GD Grenada GA Guadeloupe (Fr. Ant.) GL Guam GM Guatemala GU Guinea GE Guyana GY Haiti HC Honduras HT Hong Kong HX Hungary H Iceland IS India IN Indonesia IA Iran IR Iraq IK Ireland, Rep of EI Israel IL Italy I Jamaica JA Japan J Jordan JO Korea (South) K Korea, Dem People's Rep KZ Kuwait (Persian Gulf) KT Laos LS Lebanon LE Lesotho BB Liberia LIB Libya LY Liechtenstein FL Luxembourg LU Macao OM Madagascar MG Malawi MI Malaysia MA Maldives MF Mali MJ Malta MT Mariana Islands(Saipan) SA Martinique (Fr. Ant.) MR Mauritania, Islam Rep MTN Mauritius IW Mexico ME Monaco MC Mongolia MH Monterrat MK Morocco M Mozambique MO Nauru Islands ZV Nepal NP Nethelands Antilles NA Netherlands NL New Caledonia NM New Hebrides NH New Zealand NZ Nicaragua NK Nigeria NI Norway N Oman (Persian Gulf) MB Pakistan PK Panama PA Papua New Guinea NE Paraguay PY Peru PE Philippines PH Poland PL Portugal/Madeira/Azores P Qatar (Persian Gulf) DH Ras Al Khaimah (UAE) RK Reunion Islands RE Rumania R Rwanda RW Saint Kitts (WI) KC Saint Lucia LC Saint Pierre + Miquelon QN Saint Vincent VQ San Marino RSM Saudi Arabia SJ Senegal SG Seychelles Islands SZ Sharjah (UAE) SH Sierra Leone SL Singapore RS Solomon Islands HQ Somalia Republic SM South Africa SA South West Africa WK Spain / Canary Islands E Sri Lanka CE St Helena HI Sudan SD Surinam SN Chapter 8: Networking 125 Swaziland WD Sweden S Syrian Arab Republic SY Taiwan TW Tanzania TA Thailand TH Togo TO Tonga TS Transkei TT Trinidad and Tobago WG Tunisia TN Turkey TR Turks + Caicos Islands TQ USSR (Russia) SU Uganda UG Umm Al Qaiwan (UAE) QA United Arab Emirates EM United Kingdom / N Ire. G United States of Amer. US Upper Volta, Rep of UV Uruguay UY Venezuela VE Viet Nam VT Virgin Islands (Brit) VB Western Samoa SX Yemen Arab Rep. (San'a) YE Yemen, People's Dem Rep AD Yugoslavia YU Zaire ZR Zimbabwe RH